The ability to securely create and distribute shared secrets is one of the more fundamental requirements for a secure architecture. Typically, this function has mostly been accomplished using asymmetric cryptography (crypto) and established Public Key Infrastructure (PKI) mechanisms, including X.509 certificates and Certificate Authorities (CA's). While these methods are well-known and well-suited for traditional client-server topologies, the PKI approach can prove challenging for some emerging Internet of Things (IoT) device classes. Problematic devices may include those with more limited local computational capability or low-bandwidth network connections (or both).
While some IoT devices may have the ability to authenticate and exchange secret keys using asymmetric crypto, there are an increasingly large number of highly-connected (e.g. IoT) devices deployed that lack robust security. One problem with traditional devices is that many of the established security threat models are obsolete in todays' increasingly-connected designs. The result of outdated threat model assumptions is clearly illustrated by the infamous Miller-Valasek remote vehicle exploit that was first made public in 2015. This vulnerability served to illustrate the unforeseen dangers associated with linking systems that were designed to be secure in isolation to a widely visible communications network hub.
As such, it should be a guiding principle to assume that for new designs that they will ultimately be connected in some manner to a public network. Whether such a device's network connection is accomplished via a gateway or if the device is attached directly to the internet is certainly relevant. However, it is definitely not a realistic expectation that any connected device can rely on the ability of a gateway to isolate it from external attack. In order to design as robust a security architecture as possible, it should be assumed that any connected device will be continually subjected to external interrogation. In order to protect the operation of such connected devices from persistent attackers, all communications to and from the device should be authenticated, whether or not the data contained in the message is considered to be confidential. In this latter case, any such confidential data should also be encrypted. The essential issue then becomes one of secure key management.
In order to enable security in such a system, all devices should be provisioned with an embedded secret of some kind. In addition, any other entity with which these devices must securely communicate should also be provisioned with secrets of their own. In the asymmetric cryptography case, each of the (private) secrets has a non-secret counterpart that can be published without compromising the system's security. In the case of a symmetric cryptography-based system, devices that wish to communicate with each other must share the same secret. While it might at first glance seem that these two methodologies are fundamentally different, in practice, they share quite a few salient characteristics.
One shared attribute between symmetric and asymmetric cryptography systems is that they both require a trusted third party at some point in the process. In the case of an asymmetric system, the trusted third party may take the form of a certificate authority (CA). In symmetric crypto systems, the overall trust resides in the method by which secrets are provisioned to each of the devices. In the simplest symmetric case, there is a “trusted” location (or environment), where a shared secret can be directly transmitted between two devices without fear of some untrusted party eavesdropping on the communication. This approach generally requires physical isolation and it is thus not usually practical after a device has been deployed in the field.
A more complex (but more flexible) shared-secret system makes use of secured communications between each device and an independent trusted third party. The trusted third party exchanges information with each of the individual devices in order to enable secure connections between the untrusted devices. As with all such systems, there are certain assumptions that must be made in order to support the stated systems' security claims. The increased flexibility of such a trusted third-party exchange system is due to the fact that new keys may be provisioned to devices after they have been deployed in the field without requiring a trusted location in which to perform key exchanges or key rotations.
A less-appreciated, but nonetheless common characteristic of any approach to the problem is that both symmetric as well as asymmetric security systems depend on the ability of an individual device to maintain control of its own private secrets. For an asymmetric system, all devices must be trusted to not inadvertently reveal their own private secrets. In the case of symmetric crypto systems, more than one device must be entrusted with the safekeeping of the same shared secret. In either case, if any of these private secrets are ever exposed, the overall security of the system can break down. Thus, all secure devices must be able to retain and use a secret of some sort without exposing its value.
Accordingly, there is a need to find systems and methods by which the data of such security systems may likewise be secured, where by securing such data, the effectiveness of such a security system may be enhanced.
These, and other, aspects of the disclosure will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating various embodiments of the disclosure and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions and/or rearrangements may be made within the scope of the disclosure without departing from the spirit thereof, and the disclosure includes all such substitutions, modifications, additions and/or rearrangements.